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ABSTRACT 


There is a growing movement throughout the Department 
of Defense (DoD) towards the implementation of Network 
Centric Warfare (NCW) . In an effort to transition to NCW, 
the Navy has fielded many different technologies. One 
system exploiting new technologies in the Intelligence, 
Surveillance, and Reconnaissance (ISR) domain is the Joint 
Fires Network/Tactical Exploitation System-Navy (JFN/TES- 
N), which was developed from the Army Tactical Exploitation 
System, (TES-A). 

This system was developed rapidly and uniquely for 
fleet deployment in accordance with the interim acquisition 
guidance signed by the Honorable Paul Wolfowitz. This 
guidance authorized Evolutionary Acquisition following a 
Spiral Development process in lieu of the "traditional" 
cold war process described in the DoD 5000 series 
publications. Assuming that JFN/TES-N will be viewed as a 
successful acquisition, several Navy personnel have stated 
that it may become the model for future C4I (and other) 
system acquisitions. This thesis seeks to help develop that 
model. The objectives of this thesis are: 

• To examine whether the TES-N acquisition process 

is an appropriate model of Evolutionary 

Acquisition following a Spiral Development. 

• To identify and make recommendations for changes 
or improvements to the TES-N acquisition program, 
so it can be used as a more appropriate model for 
Evolutionary Acquisition following a Spiral 
Development. 
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This thesis concludes that Evolutionary Acquisition 
following a Spiral Development shown with the JFN/TES-N 
system is an acquisition policy that is appropriate for 
programs of the same size and scope, but larger more 
complex programs will not have as much success. Yet, in 
order for the JFN/TES-N program and future programs using 
Evolutionary Acquisition following a Spiral Development to 
succeed, changes have to be made in policies such as 
budgetary submissions, test and evaluation, policy, 
process, and training. 
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EXECUTIVE SUMMARY 


There is a growing movement throughout the Department 
of Defense (DoD) towards the implementation of Network 
Centric Warfare (NCW) . In an effort to transition to NCW, 
the Navy has fielded many different technologies. One 
system exploiting new technologies in the Intelligence, 
Surveillance, and Reconnaissance (ISR) domain is the Joint 
Fires Network/Tactical Exploitation System-Navy (JFN/TES- 
N), which was developed from the Army Tactical Exploitation 
System, (TES-A). 

This thesis explains that JFN/TES-N was developed 
rapidly and uniquely for fleet deployment in accordance 
with the interim acquisition guidance signed by the 
Honorable Paul Wolfowitz. This guidance authorized 
Evolutionary Acquisition following a Spiral Development 
process in lieu of the "traditional" cold war process 
described in the DoD 5000 series publications. Assuming 
that JFN/TES-N will be viewed as a successful acquisition, 
several Navy personnel have stated that it may become the 
model for future C4I (and other) system acquisitions. This 
thesis seeks to help develop that model. The objectives of 
this thesis are: 

• To examine whether the TES-N acquisition process 
is an appropriate model of Evolutionary 
Acquisition following a Spiral Development. 

• To identify and make recommendations for changes 
or improvements to the TES-N acquisition program, 
so it can be use as a more appropriate model for 
Evolutionary Acquisition following a Spiral 
Development. 
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In order to examine the TES-N acquisition process as a 


model for future system acquisitions, and make 
recommendations for changes to it if appropriate, this 
thesis reports the results of a literature search to 
explicitly determine the characteristics of each of these 
documented processes. Next, this thesis extracts the 
salient characteristics of the TES-N acquisition process 
through interviews with key personnel at the TES-N program 
office. Next, this thesis use the breakdown of Evolutionary 
Acquisition following a Spiral Development in the article. 
The Promise and Perils of Spiral Acquisition: A Practical 
Approach to Evolutionary Acquisition by COL Wayne M. 
Johnson, USAF (Ret) and Carl 0. Johnson as a model for 
Evolutionary Acquisition following a Spiral Development and 
the DoD 5000 series documents as a model for the 
"traditional" acquisition policy, to reveal key points that 
highlight relative differences between the two as a basis 
for characterizing the JFN/TES-N acquisition process. Next, 
the results of surveying fleet personnel show the user's 
opinion on the new system's performance. Finally, this 
thesis reports the results of interviews of operators and 
decision makers aboard the USS CORONADO, flagship of 
Commander Third Fleet (C3F) and makes recommendations based 
upon my findings for future programs with an acquisition 
process similar to Evolutionary Acquisition following a 
Spiral Development. 

This thesis concludes that Evolutionary Acquisition 
following a Spiral Development shown with the JFN/TES-N 
system is an acquisition policy that is appropriate for 
programs of the same size and scope, but larger more 
complex programs will not have as much success. Yet, in 
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order for the JFN/TES-N program and future programs using 
Evolutionary Acquisition following a Spiral Development to 
succeed, changes have to be made in policies such as 
budgetary submissions, test and evaluation, policy, 
process, and training. 
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I. 


INTRODUCTION 


A. BACKGROUND 

There is a growing movement throughout the Department 
of Defense (DoD) towards the implementation of Network 
Centric Warfare (NCW). In efforts to transition to NCW, the 
Navy has fielded many different systems and technologies. 
One such system exploiting new technologies in the 
Intelligence, Surveillance, and Reconnaissance (ISR) domain 
is the Joint Fires Network/Tactical Exploitation System- 
Navy (JFN/TES-N), which was developed from the Army's 
Tactical Exploitation System, (TES-A). 

This system was developed rapidly and uniquely for 
fleet deployment in accordance with the interim acquisition 
guidance signed by the Honorable Paul Wolfowitz. This 
guidance authorized Evolutionary Acquisition following a 
Spiral Development process in lieu of the "traditional" 
cold war process described in the DoD 5000 series 
publications. Assuming that JFN/TES-N will be viewed as a 
successful acquisition, several Navy personnel have stated 
that it may become the model for future C4I (and other) 
system acquisitions. This thesis seeks to help develop that 
model. 

B. OBJECTIVE 

The objectives of this thesis are two-fold: 

• To examine whether the TES-N acquisition process 
is an appropriate model of Evolutionary 
Acquisition following a Spiral Development. 
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• To identify and make recommendations for changes 
or improvements to the TES-N acquisition program, 
so it can be use as a more appropriate model for 
Evolutionary Acquisition following a Spiral 
Development. 

C. SCOPE AND METHODOLOGY 

1. Scope 

This thesis examined the JFN/TES-N acquisition process 
to determine whether this process should be followed as is, 
modified, or abandoned in future acquisitions. Based on 
this analysis, I made recommendations on what should be 
retained as future doctrine and what needed to be fixed. I 
also examined any problems and recommended solutions. 

2. Methodology 

Within DoD today, there are two different documented 
development and acquisition processes: the traditional 
process documented in the DoD 5000 series and the newer 
Evolutionary Acquisition following a Spiral Development 
process described in the October 30, 2002 memorandum signed 

by the Deputy Secretary of Defense, the Honorable Paul 
Wolfowitz. 

In order to assess the suitability of the TES-N 
acquisition process as a model for future system 
acquisitions, and make recommendations for changes to it if 
appropriate, I conducted a literature search to explicitly 
determine the characteristics of each of these documented 
processes. Next, I determined the salient characteristics 
of the TES-N acquisition process through interviews with 
key personnel at the TES-N program office. Next, I used the 
breakdown of Evolutionary Acquisition following a Spiral 
Development in the article. The Promise and Perils of 
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Spiral Acquisition: A Practical Approach to Evolutionary 
Acquisition by COL Wayne M. Johnson, USAF (Ret) and Carl 0. 
Johnson as a model for Evolutionary Acquisition following a 
Spiral Development and the DoD 5000 series documents, 
specifically DODI 5000.2 Operation of the Defense 
Acquisition System (Including Change 1 4JAN2001), as a 

model for the "traditional" acquisition policy, to reveal 
key points that highlight relative differences between the 
two as a basis for characterizing the JFN/TES-N acquisition 
process. I then surveyed fleet personnel to determine their 
opinion on the new system's performance. Finally, I 
interviewed operators and decision makers aboard the USS 
CORONADO, the flagship of Commander Third Fleet (C3F) and 
make recommendations based upon my findings for future 
programs with an acquisition process similar to 
Evolutionary Acquisition following a Spiral Development. 

D. RESEARCH QUESTIONS 

• What acquisition process is being used for the 

JFN/TES-N? 

• What is the "traditional" acquisition process 

described by the 5000 series publications? 

• What is Evolutionary Acquisition following a 
Spiral Development? 

• How does the JFN/TES-N acquisition process 

compare to the "traditional" cold war philosophy 
described in the 5000 series publications and the 
new process of Evolutionary Acquisition following 
a Spiral Development? 

• What recommendations can be made to improve the 

Evolutionary Acquisition following a Spiral 
Development process based on the TES-N model? 
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E. ORGANIZATION OF THE THESIS 

Chapter II provides the role, history, and background 
of TES-N, starting with how it first was developed by the 
Army, and then was adopted by the Navy. 

Chapter III provides a definition and description of 
the "traditional" acquisition process as described in the 
DoD 5000 series publications. 

Chapter IV defines Evolutionary Acquisition following 
a Spiral Development. A breakdown of Evolutionary 
Acquisition following a Spiral Development is described by 
COL Wayne M. Johnson, USAF (Ret) and Carl 0. Johnson, 
article. The Promise and Perils of Spiral Acquisition: A 
Practical Approach to Evolutionary Acquisition. 

Chapter V begins by further explaining why the United 
States needs to change their acquisition process in order 
to provide timely technology and intelligence to the war 
fighter. Next, it explains the JFN/TES-N Evolutionary 
Acquisition following a Spiral Development . This chapter 
then uses the breakdown of spiral development in the 
Johnson and Johnson article, as a model for Evolutionary 
Acquisition following a Spiral Development and the DoD 5000 
series documents as a model for the "traditional" 
acquisition policy, to reveal key points that highlight 
relative differences between the two as a basis for 
characterizing the JFN/TES-N acquisition process. 

Chapter VI provides conclusions and recommendations on 
what can be improved and what should be used in future 
acquisition programs such as the TES-N. 
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II. HISTORY OF THE TACTICAL EXPLOITATION SYSTEM 


The goal of this chapter is to provide the reader 
background on the role of the TES in its military 
environment. It also provides a history of the TES-N, 
starting with how TES first was developed by the Army and 
then adopted by the Navy. It will further present a 
background of the TES-N architecture and a description of 
how TES-N operates in its environment. 

A. BACKGROUND 

In 1973, the Army created the Army Space Program 
Office (ASPO), whose role was "developing systems to 
integrate current and emerging national capabilities into 
the decision-making process, a kind of networked 
information system." (Littman, 2002, p. 6) Since that time, 
other programs have developed similar offices known as 
Tactical Exploitation of National Capabilities (TENCAP). In 
1995, the ASPO decided to build a system called the 
Tactical Exploitation System (TES)(for simplicity in the 
thesis, the Army program will be called TES-A) that would 
consolidate intelligence such as national and theater 
imagery systems into one Multi-Intelligence system. It 
would be a scaled down version of a few existing TENCAP 
systems . These TENCAP systems to be replaced by TES-A were 
the Modernized Imagery Exploitation system (MIES), Advanced 
Electronic Processing and Dissemination System (EPDS), and 
the Enhanced Tactical Radar Correlator (ETRAC). The TES-A 
alone would provide the functional capability of all three 
systems. (Littman, 2002, p. 38) 
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The eventual commercial developer of the TES-A, 
Northrop Grumman (NG), stated that they were to deliver a 
system, which was: 

Assured receipt of all-weather, day/night 
intelligence, surveillance, reconnaissance (ISR) 
information from national, theater and tactical 
plat forms...through all phases of military 
operations, providing a real-time, correlated 
imagery and SIGINT picture directly to the 
tactical warfighter. (Littman, 2002, p. 38) 

The Army developed the TES-A as a dual-base system 
consisting of a TES Main (TES-M) and a TES Forward (TES-F) . 
"The main element (TES-M) remains in relatively secure 
locations and provides detailed intelligence analysis and 
support to the forward element (TES-F) (Littman, 2002, p. 
7) TES-F, unlike TES-M, is brought into forward areas and 
operated on the battlefield. The maneuverability of TES-F 
can be seen in Figure 1 below. 



Figure 1 . TES-Forward, Notice How the System Can Be 

Mounted and Easily Transported on Light Trucks and 
HMMWV's (From: Littman, 2002, p. 39) . 
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In 1997, the Navy began to see the potential benefits 
of adopting the TES-A to address land attack targeting from 
surface ships. They initially wanted this particular ISR 
system for three reasons: to leap ahead in technology, to 
lead to interoperability and software sharing, and to form 
a long-term relationship with the Army. (Lajoie, Interview, 
2003 and Read Ahead for NFN) 

Around this time, the Chief of Naval Reserves and 
Chief of Naval Operations N6B received permission to 
purchase a copy of the TES-A and to adapt it into what the 
Navy called the Littoral Surveillance System (LSS) . (Read 
Ahead for NFN) This first variant of TES-A, the LSS, was 
made up of TES-F and a Mobile Inshore Undersea Warfare 
System Upgrade (MIUW-SU). According to Littman: 

MIUW-SU consists of a Radar Sonar Surveillance 
Center (RSSC) van, which is used as a command 
center and an array of sensors. The sensors 
include radar for aircraft detection and sonobuoy 
processing for underwater target detection. This 
was to provide complete littoral area 
surveillance. (Littman, 2002, p. 7) 

During 1998 through 2000, the LSS was built and tested 
in Fleet Battle Experiment-Echo (FBE-E). (Littman, 2002, p. 
7) 

Later, Navy variants of the TES-A called the TES-N, 
Remote Terminal Components (RTC) and Remote Terminal 
Components Lite, were developed and deployed by the Navy. 
Each variant is different, and used for different levels of 
activity. Figure 2 depicts the three variants of TES-N used 
today. 
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Sensor Servers 
-TES 


Remote Servers 
- RTC 



Client 

-RTC-LITEs 



Figure 2. The TES-N, RTC, and RTC-Lite (From: Thomas, 
Joint Fires Network Overview, January 2003). 

The Navy's vision, of TES-N, is part of a system of systems 
providing an end-to-end architecture for Time Sensitive 
Targeting (TCT) . However, the TES-N is only one component 
of the system of systems. The others are currently JSIPS-N, 
GCCS-M and an undetermined fire management system 
generically referred to as Integrative Cooperative 
Engagement (ICE). (Lajoie, Interview, 2003) In naming the 
TES-N, RADM Mullen (now VADM selected to ADM), as N76, 
coined the TES-N as Naval Fires Network (NFN) /TES-N as he 
was preparing his Congressional briefings. This later was 
renamed Joint Fires Network (JFN)/TES-N. (Burns, 2003) 






















The TES-N is a complete system, and is equipped with 
sensor servers which allow direct connectivity to the 
sensor. The RTC has remote servers which cannot talk 
directly to the sensors. They must receive the sensor 
information via a full TES or some other intermediary, but 
possess full processing capability. The RTC-Lites are 
basically laptops/clients that are only used for visual 
display of information in the fleet . (Lajoie. Interview, 
2003) Figure 3 is a closer view of the Remote Terminal 
Component aboard the USS Coronado. 



Figure 3. Remote Terminal Component. (From: Littman, 

20 02, p. 52) . 

At this time, the Navy realized that they were 
deficient in the TCT of NCW. Therefore, a key mission 
capability that the Navy was trying to achieve using TES-N 
was TCT. Through Fleet Battle Experiments (FBE) and Limited 
Objective Experiments (LOE), the program office IWS 6C 
wanted to ensure that the TES-N provided the capability to 
do "Time Critical Targeting against rapidly relocateable 
targets." (NFN Read Ahead for N76) The goal of the TES-N 
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was to be able "... to correlate multiple off ship sensors' 
data and intelligence with information from the tactical, 
theater, and national levels." (Littman, 2002, p. 41) In 
the end, JFN/TES-N would be able to collect data from the 
sources of intelligence listed below with the ability for 
Cross-Intelligence application and nodal analysis. 

• SIGINT 

• National data 

• Real-time interface 

• Theater SIGINT 

• Modified GALE 

• Real-time sensor control / tasking 

• Combat assessment 

• Imagery 

• National imagery 

• Direct Down Link (DDL) theater imagery 

• COTS package for exploitation 

• Real-time sensor control/tasking 

• Accurate geo-location 

• MTI 

• Multiple Theater feeds (e.g. Global Hawk) 

• Auto track and correlation 

• Cross-cue/overlay (Thomas, Joint Fires 
Network Overview, 2003) 

Figure 4 shows how this would work. 
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Figure 4. TES-N Sensor Inputs (From: Littman, 2002, p. 

42) . 

Throughout the TES-N development and fielding. 
Commander 3 rd Fleet (C3F) was an early sponsor and made an 
active part of the TES-N lifecycle. C3F continually 
monitored the productivity and functionality of the system. 
Later, Third Fleet helped to conduct FBE and LOE to improve 
TES-N because they realized it would help with operations 
such as land attack and force protection in the fleet . 
(Thomas, Interview, 2003) 

In 2001, the TES-N was delivered to the USS Coronado. 
Installing it on a ship brought operational insight to the 
system engineers developing TES-N. Due to the 
infrastructure of the ship, they could install the TES-N 
without the infrastructure that the Army had used with TES- 
A. Next, when the TES-N became operable on ships, the Navy 
started to test the system through a series of LOE. 
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Around this same timeframe, all systems of the TES 
(meaning all variants of TES-A and TES-N) were being built 
with an open and common architecture. The open architecture 
of TES entails a common standard where no proprietary 
hardware was used. It was all either government owned or 
commercial, and computer components were required to be 
commercial off the shelf. This was done so that it would 
take less money to change components in the future . The 
common architecture of the TES also means that all services 
use a common software version, which was intended to mean 
that there was a core version, and if one service needed a 
new entity for the core, then they were entitled to build 
it to fit the core while still making it readily available 
to other services if they wanted its capability. (Lajoie, 
Interview, 2003) In addition each service was funding its 
individual requirements, but all services got to benefit 
from the new capabilities added to the core. So far, this 
cost sharing arrangement and joint configuration management 
has proven to be very beneficial. (Burns, 2003) Therefore, 
two rules were that no service could change the core and no 
service could make a unilateral change if it affected the 
core or hurt another service. 

Also around this time, the United States Air Force 
(USAF) and United States Marine Corps (USMC) began to 
acquire variants of the TES. The USMC referred to it as the 
Tactical Exploitation Group (TEG) and the USAF referred to 
it as the Intelligence, Surveillance and Reconnaissance- 
Manager (ISR-M). The Marine Corps, like the Air Force, 
realized that the interoperability of the system was a 
great idea because they would benefit from the sharing of 
targets and ISR. The Marine Corps also realized that to 


12 



obtain this capability, they only had to evaluate and 
update their system called, TEG. (Lajoie, Interview, 2003) 
Even though, TEG and ISR-M have the same functionality as a 
full TES-N or TES-A due to their common software baseline, 
each service can chose doctrinally to use the system to 
meet their specific service requirements and may or may not 
take advantage of all the inherent tools and capabilities. 
The common software, however, allows sharing of raw and 
processed sensor data, targeting information, and other ISR 
and Intelligence Preparation of the Battlefield (IPB) 
collaboration. (Burns, 2003) 

Fortunately, the Army in 1999 had also made a "virtual 
program office" for the development of the TES that 
included all the services called the Joint Commonality 
Board (JCB). (Lajoie, Interview, 2003) The Joint 
Commonality Board is a virtual program office that acts 
like one chain of command, but in reality, it does not 
function that way. Ideally, all the services meet with 
their user requirements and vet out which requirements are 
going to be developed. Yet, each service is answering to 
their respective chain of commands and making sure that 
their services requirements are also being met. From the 
beginning, all services were on board but only the Navy and 
Army were contributing money. (Lajoie, Interview, 2003) 
Since the TES-N is constructed with a common architecture, 
the program office is currently working on Version 6.0 of 
the software and has fielded some of these TES systems seen 
below in Figure 5. 
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FIELDED TES SYSTEMS 
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Figure 5. Fielded TES Systems (From: Thomas, Joint 

Fires Network Overview, January 2003) . 


As for its hardware technology, since Moore's law states 
that the computing power of a computer will double every 18 
months, the TES-N will continue to be updated each year to 
keep up with hardware changes. The TES-N will also be 
updated to changes in user's needs. Below is a figure of 
what the TES-N program office (IWS 6C) hopes to accomplish 
in 2003. This list is more specific to the Navy's needs but 
there are also requirements that the Army, USMC, and USAF 
hope to accomplish. 
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PMS 454 P3I activity in 2003 


• AMSTEII Integration 

• JTAAC integration 

• ADOCS/AFATDS Integration 

• Tactical Control System 

• NCCT Integration 

• SIGINT Targeting 

• CADP Development 

• Classified Sensor Integration 

• RTC Lite Development 

• Tactical Dissemination Module 

• Improved Networking 

• Force Protection Package 


Fire Control & Weapon Quality MTI 
Adaptation of A ADC Functionality for Land Attack 
Engagement Grid Interface 
Integration of Common UAV Control System 
Airborne Sensor Networking (EP-3, EA-6B, RJ, etc.) 
Fire ControlAVeapon Quality SIGINT Geo-location 
X, Ku Phased Array Antenna Development 
Classified (2 Different Sensors) 

Windows based TES data access and Display 
Move Aircraft uplink from LOS to Link 16 to IP 
Improve TES Networking & DB replication 
Integration of Force Protection Sensors 


Figure 6. PMS 454 P3I Activity in 2003 (From: Thomas, 

Joint Fires Network Overview, January 2003) . 

B. THE SIX LAYER PICTURE OF THE TES-N 

In order to understand the composite picture of the 
TES-N, one must understand the TES-N's six-layer picture. 

TES-N creates a composite picture for the 
tactical war fighter by stacking all of its 
inputted data in a logical way. Essentially, six 
different layers make up the composite picture 
This stack...is built by combining the data from 
the many sources including: electronic 

maps/charts, tactical and national imagery 
(IMINT), Moving Target Indicator (MTI) and track 
data from airborne sensors, signals intelligence 
(SIGINT) both from the Miniaturized Data 
Acquisition System (MIDAS) and from the global 
broadcast system (GBS), graphical data, and 
imagery interpretation reports (HR). TES-N can 
then display the composite data in various ways 
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that can support the myriad missions today's 
warfighters find themselves in. (Littman, 2002, 
p. 40) 
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Figure 7 . Stacked Information Layers (From: Littman, 

2002, p. 43) . 

The TES-N architecture is made up of six layers, each 
possessing different functions. More specifically, the 
first or base layer is composed of maps so that the system 
can obtain latitudes and longitudes for its targets and 
intelligence data. The digital maps, which can be updated 
as needed, are taken from the National Imagery and Mapping 
Agency (NIMA) . Layer 2 is made up of tactical and national 
imagery. Tactical imagery comes from numerous air and 
ground sensors such as F-18's and UAV's. Layer 3 ..."is 

composed of Moving Target Indicator (MTI) and other track 
data sent to TES-N from a [capable] aircraft." (Littman, 
2002, p. 48, The word capable is not in the quote) The 
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fourth layer receives signals intelligence from sources 
such as National SIGINT, SCI level SIGINT, and SIGINT from 
the Miniaturized Data Acquisition System (MIDAS). The fifth 
layer is made up of the Graphical Situation Display (GSD) , 
which helps improve the asset organization and the 
commander's situational awareness. The sixth layer's 
Imagery Interpretation Reports (HR) further improves the 
commander's situational awareness and asset organization. 
"All six of the layers' functionalities can be toggled on 
or off by the operators to produce the most relevant 
picture for a given situation." (Littman, 2002, p. 50) 
Finally, to locate information, an operator has flexibility 
within each layer by being able to scale in or out for the 
data required. 

C. HOW THE JFN/TES—N WORKS 

The JFN/TES-N is a joint end-to-end architecture for 
Time Sensitive Targeting. The system merges the 
capabilities from ISR, targeting, mission planning, and 
situational awareness in order to strike an accurate 
target. As seen in Figure 8 below, the TES-N first detects, 
collects and displays the data from sensors and data links 
in real time. This data is then exploited using its 
intelligence subsystems so that commanders can make real 
time, accurate decisions about targets. These targets are 
assigned to different weapons systems so that they can be 
attacked. (Blackledge, 2002, p. 5) 
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Figure 8. 

(From: 


A Picture of What JFN Provides to the User 
Thomas, Joint Fires Network Overview, 2003) . 
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III. THE TRADITIONAL (AS DESCRIBED BY THE 5000 
SERIES PUBLICATIONS) APPROACH TO ACQUISITION 


This chapter provides the reader with an understanding 
of the acquisition process and policy that has been 
developed over the past fifty plus years . Readers need to 
understand the old process to better understand the changes 
and why these changes are being made. 

Since before the cold war, DoD's systems acquisition 
has been following a policy that prescribes a phased 
process for developing a system. This process follows a 
path of finishing one activity, obtaining approval and then 
proceeding to the next activity. Each year the DoD also has 
an established way of submitting a budget so that they can 
allocate obligation authority to each program accordingly. 
Furthermore, there is a policy for conducting tests and 
evaluations for programs. The phased process is a formal 
and organized way of acquiring systems, which has been 
used, evolved, and tailored for over fifty years, but due 
to rapidly changing technology, many believe that this 
acquisition policy is performed in an inefficient way that 
produces outdated results . Some key points I hope to 
highlight in this chapter are that the "traditional" 
process is accomplished in phases and milestones, it must 
have an Operational Requirements Document (ORD) and Mission 
Needs Statement (MNS), and policies such as budgetary 
submissions and test and evaluation are developed according 
to this old policy. 
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A. THE DODI 5000.2 ACQUISITION PROCESS 

According to DoDI 5000.2, Operation of the Defense 
Acquisition System, an acquisition program is: 

A directed, funded effort designed to provide a 
new, improved, or continuing materiel, weapon, or 
information system or service capability in 
response to a validated operational or business 
need. Acquisition programs are divided into 
different categories that are established to 
facilitate decentralized decision-making, 
execution, and compliance with statutory 
requirements. Technology projects are not 
acquisition programs. (Defense Acquisition Desk 
Book Site, DODI 5000.2 Operation of the Defense 
Acquisition System, Enclosure E2.1.2) 

The Defense Acquisition System consists of a series of 
phases and control gates which control the development of a 
new program by balancing the risks and benefits while 
controlling the costs of that system. DoDI 5000.2 
establishes the Defense Acquisition System as a process, 
which translates a user's Mission Needs Statement and 
business requirements, and the latest technology 
capabilities into a system that is useful for the user. A 
model of a defense acquisition management program is shown 
below. It is broken down into three activities called Pre- 
Systems Acquisition, Systems Acquisition, and Sustainment. 
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THE 5000 MODEL 
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Figure 9. The 5000 Model (From: Defense Acquisition 

Desk Book Site, DODI 5000.2 Operation of the Defense 

Acquisition System). 


These three activities are then further divided into 
four more phases, the first and third activity having one 
phase and the second activity having two phases. For 
example, the first phase is Concept and Technology 
Development. Next, each phase is divided into the specific 
work efforts achieved in that phase. For example, the work 
efforts in the Concept and Technology Development phase are 
Concept Exploration and Component Advanced Development. 
These are described below. Each phase also has entrance and 
exit criteria, which establish whether the project is ready 
to enter or exit its future or existing phase respectively. 
Entrance criteria for a phase are the minimum 
accomplishments that must be completed by a program before 
it is allowed to enter the next phase . Similarly, exit 
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criteria are defined as program specific results that must 
be reached by the end of the phase. In addition, there are 
three important milestones in the overall process. The 
program office must ensure that there is an approved MNS in 
order to start the program at Milestone A, which happens 
before Concept Exploration. To pass Milestone B, which 
occurs right before Systems Integration, they must ensure 
they have an approved ORD. In order to proceed past 
Milestone C, which is right before the work effort known as 
Low-Rate Initial Production, the system must be approved 
for low rate initial production by the correct approving 
authority. 

B. THE DESCRIPTION OF THE DODI 5000.2 MODEL 

During the Pre-Systems Acquisition action, which is 
also known as the Concept and Technology phase, the key 
objectives are to ascertain user requirements and the 
technological opportunities that are available for the new 
system. This phase is divided into work efforts called 
Concept Exploration and Component Advanced Development (as 
seen below). 

In the Concept Exploration stage, the program office 
conducts paper studies of alternative concepts for meeting 
the user requirements listed in the MNS. The exit criterion 
for Concept Exploration is that the program office realizes 
that they have a specific concept that can be developed 
with existing technology. The program office enters the 
Component Advanced Development stage to start the system's 
architecture once they are sure the concept is sound. In 
this stage, the engineers continually study concepts that 
might be helpful to further technological advancement of 
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this system. In order for the program to proceed to the 
next phase, it is necessary to demonstrate that the system 
architecture and technology of the system are in their 
relevant environments as described by the MNS. 


Concept and Technology Development 
Work Content 



Concept 

Exploration 


/ 


Concept Exploration 

Paper studies of alternative 
concepts for meeting a need 


Component 

Advanced 

Development 


Decision 

Review 


\ 


Component Advanced Da/elopmerit 

' Development of subsystems/components 
that must be demonstrated before 
integration into a system 


• Concept/tech demonstration of new system 
concept(s) 


Figure 10. Concept and Technology Development Work 

Content (From: Defense Acquisition Desk Book Site, 
DODI 5000.2 Operation of the Defense Acquisition 

System). 

The next activity is the Systems Acquisition Activity, 
which occurs across both the System Development and 
Demonstration Phase and the Production and Deployment 
Phase. DoDI 5000.2, Operation of the Defense Acquisition 
System, states that: 

The purpose of the System Development and 
Demonstration phase is to develop a system, 
reduce program risk, ensure operational 
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supportability, design for producibility, ensure 
affordability, ensure protection of Critical 
Program Information, and demonstrate system 
integration, interoperability, and utility. 
Discovery and development are aided by the use of 
simulation-based acquisition and test and 


evaluation and guided by a system acquisition 
strategy and test and evaluation master plan 
(TEMP). System modeling, simulation, test, and 
evaluation activities shall be integrated into an 
efficient continuum planned and executed by a 
test and evaluation integrated product team (T&E 
IPT) . (Defense Acquisition Desk Book Site, DODI 
5000.2 Operation of the Defense Acquisition 
System, 4.7.3.2.1.1) 

The System Development and Demonstration Phase is 
divided into two system work efforts: Systems Integration 
and Systems Demonstration (as seen below). 


System Development and Demonstration 
Work Content 
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Figure 11. System Development and Demonstration Work 


Content (From: Defense Acquisition Desk Book Site, 
DODI 5000.2 Operation of the Defense Acquisition 

System). 
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In Systems Integration, the program office 
concentrates on the integration of subsystems and the 
cutback of integration risk. In order to enter into Systems 
Demonstration, the prototypes developed in System 
Integration must be functioning in a relevant environment. 
During Systems Demonstration, the systems engineers and 
contractors complete development, demonstrate engineering 
development models, and conduct combined developmental and 
operational testing. The program may exit this phase and 
enter the Production and Deployment activity only after 
sufficient testing and a successful system demonstration in 
its intended environment. 


In the Production and Deployment Phase, the program 
office hopes to establish an operational capability that 
was requested earlier through the MNS . This phase is also 
further divided into two parts: Low-Rate Initial Production 
and Full-Rate Production and Deployment (as seen below). 
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Figure 12 . Production and Deployment Work Content 

(From: Defense Acquisition Desk Book Site, DODI 5000.2 
Operation of the Defense Acquisition System). 
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In order for a program to start Low-Rate Initial 
Production, the program must obtain approval from the 
Milestone Decision Authority (MDA) (discussed below). This 
will ensure that the program office has completed a list of 
requirements such as an approved ORD, acceptable 
interoperability, suitable operational supportability, 
demonstration that the system is affordable throughout the 
life cycle, adequate information assurance to include 
information assurance detection and recovery, and up to 
standard anti-tamper provisions. During Low-Rate Initial 


Production, 

not 

only is 

the system 

going through 

low-rate 

production. 

but 

it also 

has a set 

of tests that 

it must 

pass, such 

as 

initial 

operational 

test and evaluation 


(IOT&E) and live fire test and evaluation (LFT&E) . It also 
must be established whether the system is ready for full- 
rate production (FRP). Once the system has been deemed 
operationally effective by the Operational Test and 


Evaluation 

Force (OPTEVFOR) and 

ready 

for 

full-rate 

production 

, it is then 

allowed to 

enter 

the 

Full-Rate 

Production 

and Deployment 

stage. In order 

to 

exit this 

activity. 

the system must 

have full 

operational 

capability 


and the deployment must be complete. 

Finally, the purpose of the last activity, entitled 
Sustainment, is to provide affordable support of the system 
throughout its life cycle. This activity is called the 
Operations and Support Phase and is also divided into two 
parts: Sustainment and Disposal (as seen below). 
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Operations and Support 
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Figure 13. Operations and Support Work Content (From: 

Defense Acquisition Desk Book Site, DODI 5000.2 
Operation of the Defense Acquisition System). 


In the first part, the work effort is concentrated on 
operational support and in the latter; it focuses on 
disposal or demilitarization of the system. For the 
purposes of this thesis, the description of the 5000.2 
model, which is the baseline for "traditional" acquisition, 
is complete. 

C. CATEGORIES OF ACQUISITION POLICY 

There are three different acquisition categories in 
the "traditional" process of acquisition as explained by 
the 5000 series documents. The process which each program 
follows depends on the specific acquisition category in 
which it is placed. The different acquisition categories in 
order from largest/most complex to smallest/simplest, are 
Acquisition Category I, (ACAT I), Acquisition Category II 
(ACAT II), and Acquisition Category III (ACAT III) . Each 
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category has requirements, which the program office must 
meet and obtain approval for before they proceed to the 
next activity in the "traditional" process . In addition, 
all acquisition programs should have a MDA; of course, the 
rank and position of the MDA varies according to ACAT . 
Therefore, each program is mapped into one of three 
categories, where they follow similar regulations but at 
varying degrees of authority. 

D. OBLIGATION AUTHORITY 

Finally, the way in which obligation authority is 
allocated for each system development is directly linked to 
the "traditional" process of acquisition as described by 
the 5000 series publications. Right now the DoD uses a 
system called The Planning, Programming, and Budgeting 
System (PPBS), whose purpose "is to provide the optimal mix 
of forces, equipment, and support, which can be achieved 
within fiscal restraints." (AFMC Financial Management 
Handbook, Updated December 2001) The PPBS is a plan for 
developing DoD's budget request, which is sent to the 
president for approval and made a part of the President's 
Budget that is sent to Congress. Within the PPBS: 

the odd-numbered calendar years are used to 
concentrate on the DoD planning process. During 
the even-numbered years, the Services formulate 
and submit their Program Objective Memorandum 
(POM) and BES (Budget Estimate Submissions) to 
the OSD (Office of the Secretary of Defense). The 
PPBS is a continuous process with PPBS activities 
from one year overlapping with PPBS activities 
applicable to other years . (AFMC Financial 
Management Handbook, Updated December 2001) 
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Congress knows how much obligation authority the 
program office desires for each system based on these 
submissions, and then later decides how much they are 
willing to appropriate for each program. Congress knows the 
desires of the program office since each service has stated 
the amount of obligation authority needed and its purpose 
in their POM and BES . This process is efficient for the 
phased process described by the 5000 series documents, but 
for Evolutionary Acquisition following a Spiral Development 
this would not be effective since Program Managers do not 
know the purpose of their obligation authority so far in 
advance. 

This acquisition policy has been followed since before 
the Cold War. It is a phased process consisting of a series 
of phases and control gates, which control the development 
of a new program by balancing the risks, costs, and 
benefits of that system. This process also follows 
budgetary rules set up by the DOD's PPBS . This acquisition 
policy, along with other budgetary and testing policies, 
are considered outdated processes which need to be changed 
so that changes in today's technology can be more 
effectively tracked. 
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IV. EVOLUTIONARY ACQUISITION FOLLOWING A SPIRAL 

DEVELOPMENT 


A. THE SPIRAL PROCESS DEFINITION 

The goal of this chapter is to provide the reader with 
a clear understanding of Evolutionary Acquisition following 
a Spiral Development. 

As can be seen, the phased process described in the 
Department of Defense 5000.2 directive draws system 
development and acquisition out over a long period of time. 
Unfortunately, developments with this phased process might 
not be ready for use until several years later. This is 
disadvantageous to the United States especially when 
dealing with C4I systems since information technology is 
changing so rapidly. Therefore, the DoD acquisition policy 
needs to produce higher performance, with a more rapid 
deployment of the system. The acquisition policy that has 
been in use since before the Cold War needs to be changed. 
Some major goals of this new process would be to lessen the 
restrictiveness used in the policy by giving more flexible 
decision authority to the program manager. (Evolution of 
the DOD Acquisition Process: In a Nutshell) 

Most of these changes were enacted on October 30, 
2002, when Deputy Defense Secretary the Honorable Paul 
Wolfowitz signed guidance that gave relief from some of the 
current policies outlined in documents such as: DOD 
Directive 5000.1, "The Defense Acquisition System"; DOD 
Instruction 5000.2, "The Operation of the Defense 
Acquisition System"; and DOD 5000.2-R, "Mandatory 
Procedures for Major Defense Acquisition Programs and Major 
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Automated Information System Acquisition Programs." Deputy 
Defense Secretary Wolfowitz wrote that "the intent of the 
guidance is to rapidly deliver affordable, sustainable 
capability to the warfighter that meets the warfighter's 
needs." (Plummer, 2002) The Honorable Mr. Wolfowitz 
continued to say that this new policy would hopefully 
create an environment in the acquisition community that 
would encourage "efficiency, flexibility, creativity and 
innovation." The hope of this new directive was to give 
program offices the freedom to streamline their programs as 
they saw fit. Yet, he still hoped that they would develop 
systems whose standards were just as high. (Plummer, 2002) 

The type of acquisition that the Honorable Mr. 
Wolfowitz promoted is Evolutionary Acquisition following a 
Spiral Development. According to the Department of Defense: 

Evolutionary acquisition is DoD's preferred 
strategy for rapid acquisition of mature 
technology for the user. An evolutionary 
approach delivers capability in increments, 
recognizing, up front, the need for future 
capability improvements. The success of the 
strategy depends on the consistent and continuous 
definition of requirements and the maturation of 
technologies that lead to disciplined development 
and production of systems that provide increasing 
capability towards a materiel concept. 

(http://dod5000.dau.mil/Memo500020ct30.doc) 

Evolutionary Acquisition following a Spiral 
Development is completely different . It cannot be carried 
out following the "traditional" acquisition process as 
described by the 5000 series documents. It needs to follow 
a spiral process, a process where: 

...a desired capability is identified, but the end- 
state requirements are not known at program 
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initiation. Those requirements are refined 
through demonstration and risk management; there 
is continuous user feedback; and each increment 
provides the user the best possible capability. 

The requirements for future increments depend on 
feedback from users and technology maturation. 

(http://dod5000.dau.mil/Memo500020ct30.doc) 

This Evolutionary Acquisition following a Spiral 
Development can be viewed below. The figure tries to depict 
that there is an initial desired capability but the end 
product is not known. It further emphasizes that at the end 
of each spiral user feedback is analyzed along with changes 
in technology to produce new requirements for the next 
spiral. This process happens faster than the "traditional"' 
process as described by the 5000 series documents and 
produces a product to the fleet at the end of each spiral. 



Figure 14. A Figure Depicting Evolutionary Acquisition 

following a Spiral Development (From: 
http://dod5000.dau.mil/Memo500020ct30.doc). 
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B. EVOLUTIONARY ACQUISITION FOLLOWING A SPIRAL PROCESS 

A literature search of articles and doctrine on 
Evolutionary Acquisition following a Spiral Development 
such as DoD doctrine from memos entitled Operation of the 
Defense Acquisition System, and articles by Dr. Stuart 
Starr, The Requirements Process for the Acquisition of 
Command and Control Systems: Needs, shortfalls, and 
Challenges, and the article. Assessing Military Information 
Systems , revealed COL Wayne M. Johnson, USAF (Ret) and Carl 
0. Johnson's breakdown of Evolutionary Acquisition 
following a Spiral Development in their article. The 
Promise and Perils of Spiral Acquisition: A Practical 
Approach to Evolutionary Acquisition, to be most helpful 
and accurate. 

There are key facts of the Evolutionary Acquisition 
following a Spiral Development that a program office must 
know and consider before adopting it into their program. 
One must first realize that Evolutionary Acquisition 
following a Spiral Development will not work for all 
programs. In my opinion the "traditional" approach as 
described by the 5000 series documents would be better for 
larger/ more complex programs. There are specific 
characteristics, which Evolutionary Acquisition following a 
Spiral Development is appropriate. For example, Johnson and 
Johnson state: 
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The intended spiral acquisition characterist ics 
are large proportion of commercial technology or 
previously developed military technology; a 
desire to shorten technology insertion life 
cycles; schedule urgency; flexibility in 
requirements for later insertions and budgetary 
uncertainty. (Johnson and Johnson, Summer 2002, 
p. 177) 

Also, unlike the phased approach explained earlier, 
the program office using Evolutionary Acquisition following 
a Spiral Development usually has an end goal but each 
spiral is not completely developed beforehand, and 
therefore, not preplanned until the next spiral. This means 
that the program office can only determine what needs to be 
accomplished in the next spiral by determining what was 
finished effectively in the current spiral . Thus, the main 
goal of the Evolutionary Acquisition following a Spiral 
Development is developing a series of smaller projects, 
which in turn, are returned to the user more rapidly. 

Johnson and Johnson then break up the Evolutionary 
Acquisition following a Spiral Development into three main 
components, which can be summarized under the titles 
Requirements Definition, Acquisition Strategy, and 
Employment Concept. These three components help define what 
is needed for a spiral. 

1. Requirements Definition 

For the Requirements Definition component of this new 
approach, Johnson and Johnson state, "the user has to be 
involved up front and understand the desired end state 
solution will not come with the first delivery." (Johnson 
and Johnson, Summer 2002, p. 178) Next, the program must 
have a way of doing business that includes the user in each 
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increment of the spiral. This means that the user must help 
determine at each spiral what the program needs and then 
there must be a process through which the program office 
and the user both decide on what is essential for the next 
spiral of the project. Thus, continuous communication, 
trust, teamwork and regularly held meetings are essential 
for obtaining the correct requirements and achieving 
success within each spiral. The system requirements are 
stated in a document that resembles an ORD from the 
"traditional" 5000 series approach, but it is called a 
Spiral Requirements Document (SRD) instead. This document 
lists the user's essential requirements for the system, but 
the users also have an understanding that the system might 
be less than perfect or 80% effective. The users "... will 
test it, field it, and use it knowing it does not meet all 
their needs, but it does have operational utility." 
(Johnson and Johnson, Summer 2002, p. 179) Therefore, there 
must be flexibility and balance between the users and the 
program office to establish the requirements. One can 
already see the three main differences between the 5000 
series approach. "First, in a [Evolutionary Acquisition 
following a] Spiral [Development] ...the program developer 
may make improvements that do not readily seem to support 
the end goal." (Johnson and Johnson, Summer 2002, p. 180, 
the words Evolutionary Acquisition following a and 
Development are not in the quote) Next, the Evolutionary 
Acquisition following a Spiral Development allows for the 
developer to more easily put leading edge software into the 
system. Lastly, in Evolutionary Acquisition following a 
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Spiral Development, at the end of each spiral, the item is 
not considered to be complete. Instead, another spiral will 
be used to produce an upgrade quickly. 

2. Acquisition Strategy 

Next, the program office must develop an Acquisition 
Strategy, which is a framework for translating the 
requirements into actions. For this strategy, the program 
office needs to develop constant communication and teamwork 
with the users, developers. Spiral Development Integrated 
Product Teams, and the Program Office. This includes 
scheduled meetings of a Spiral Development Integrated 
Product Team. This team will help the program office 
provide insight to the user. 

Flexibility like in the phased approach is also 
important in the Acquisition Strategy. First, the program 
manager must look for long-term flexibility in the project, 
and must realize that appropriations from Congress can 
change, and therefore, must be willing to accept budget 
cuts . A solution for budget cuts for Evolutionary 
Acquisition following a Spiral Development that cannot be 
done in the phased approach would be to move a requirement 
from one spiral to the next. Another difference between the 
phased approach and Evolutionary Acquisition following a 
Spiral Development is that flexibility in testing must also 
exist. "The testing community cannot become rigidly fixed 
on an end requirement or a [Evolutionary Acquisition 
following a] Spiral Development will not work." (Johnson 
and Johnson, Summer 2002, p. 181, the words Evolutionary 
Acquisition following a are not in the quote) Therefore, 
testing procedures need to be assessed so that user is 
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still getting a safe product but with the understanding 
that more testing is needed before there will be an end 
result. In Evolutionary Acquisition following a Spiral 
Development, one must also learn how to manage risk by not 
allowing the burden of success to be based on too much 
technology or capability in one spiral at a time. 
Therefore, Johnson and Johnson recommend breaking up the 
development into smaller compartments. In other words, 
"keep the critical path simple and singular." (Johnson and 
Johnson, Summer 2002, p. 181) 

3. Employment Concept 

The Employment Concept component of Evolutionary 
Acquisition following a Spiral Development can be a little 
more challenging than the approach described by the 5000 
series documents, but the output is produced more quickly. 
In this part of Evolutionary Acquisition following a Spiral 
Development, the user must work directly with the program 
office and testers to determine "...the priority list of 
capabilities they would like to see fielded. This gives the 
program office a means to make focused decisions." (Johnson 
and Johnson, Summer 2002, p. 183) This is more challenging 
in Evolutionary Acquisition following a Spiral Development 
because the Program office is continuously getting new user 
requirements and then making sure that the testers and 
engineers know and agree with these requirements. The 
challenge is that these requirements are constantly 
changing as opposed to the phased approach were once the 
requirements are composed they do not usually change as 
rapidly. 
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The logistics team during Evolutionary Acquisition 
following a Spiral Development must be very skilled because 
there are usually multiple configurations of the system 
fielded at the same time. The multiple configurations of 
the system are disadvantageous, but this happens today with 
the 5000 series approach due to unplanned occurrences, and 
in the spiral approach, the program office is doing upfront 
planning for this logistics challenge by realizing that 
with each spiral there is a different system produced. 
Therefore, logistics representatives early on are prepared 
for different configurations of the same development making 
it easier for maintenance and training. 

In conclusion, there are many advantages to 
Evolutionary Acquisition following a Spiral Development and 
some disadvantages. Some advantages over the traditional 
form of acquisition are that capabilities are delivered 
quicker to the warfighter, the program office can manage 
risk more efficiently. Evolutionary Acquisition following a 
Spiral Development is more receptive to user needs, and 
technology changes can be applied to the system more 
easily. Some aspects to be cautious of when using 
Evolutionary Acquisition following a Spiral Development for 
their program are: Evolutionary Acquisition following a 
Spiral Development could be looked at as an easy budget cut 
by Congress due to its flexibility between spirals, test 
teams must realize that partial capability must be looked 
at initially, logistics teams must be willing to support 
multiple configurations that are fielded, the user must 
understand that they are not going to get their final 
product in the first spiral but probably an 80% effective 
system, and they must understand that their program will be 


39 



subject to false comparison. "... The question will be, 'Why 
fund the new system that does not greatly perform over the 
older system?'" (Johnson and Johnson, Summer 2002, p. 186) 
Even with these drawbacks to Evolutionary Acquisition 
following a Spiral Development, the benefits in the long 
run are significant for many programs. 

Evolutionary Acquisition following a Spiral 
Development is the acquisition policy of the future for 
most systems. It has many advantages and some 
disadvantages. Overall there must be a strong relationship 

with users, contractors, the program officer, and testers 
for this Evolutionary Acquisition following a Spiral 
Development to work. 
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V. 


THE TES-N ACQUISITION PROCESS 


This chapter further explains why the United States 
needs to change its acquisition policy in order to provide 
timely technology and intelligence to the warfighter. Next, 
it explains the JFN/TES-N Evolutionary Acquisition 
following a Spiral Development process. This chapter then 
uses the breakdown of Evolutionary Acquisition following a 
Spiral Development in the Johnson and Johnson article as a 
model for Evolutionary Acquisition following a Spiral 
Development and the DoD 5000 series documents as a model 
for the "traditional" acquisition policy. These models are 
then compared to reveal key points that highlight relative 
differences between the two, and these differences serve as 
a basis for characterizing the JFN/TES-N acquisition 
process. 

A. TIMELY INTELLIGENCE AND SUCCESS IN WARFARE 

History has shown that timely intelligence can lead to 
improved battlefield performance. In June 1941, in the 
Battle of Midway, the United States defeated the Japanese 
in a battle that demonstrated how timely intelligence 
provided to the warfighter could change the outcome of a 
battle. ADM Yamamoto Isoroku's command had major advantages 
in force structure, technology, training, experience, 
morale, and inertia. Yet ADM Chester W. Nimitz, whose only 
advantage was in timely intelligence, was victorious over 
the Japanese. (Blackledge, 2002, pp. 3-4) 
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The United States Navy learned from engagements like 
the Battle of Midway that timely intelligence was necessary 
for success in the past. Now we are engaged in a new type 
of warfare —War on Terrorism— where timely intelligence is 
even more important. Fortunately, at the same time that the 
War on Terrorism began, the Navy was in the process of 
fielding a new system, TES-N, which provided a great 
capability for gathering and disseminating this 
intelligence . However, the only way to rapidly deploy this 
system to support the war on terrorism was through an 
Evolutionary Acquisition following a Spiral Development 
B. THE STEPS THAT LED TO TES-N DEVELOPMENT 

On September 11, 2001, hijackers of two commercial 

planes crashed them into the twin towers of the World Trade 
Center in New York City, killing all passengers and large 
numbers on the ground. Later a third commercial plane was 
crashed into the Pentagon, causing hundreds of deaths and 
turmoil in our country's center of military leadership. The 
next crash of a passenger plane by terrorists occurred in 
Pittsburgh, killing everyone onboard, 

(http://abcnews.go.com/ sections/us/DailyNews/WTC_MAIN010 911 
.html) Due to these attacks. Congress turned to the 
military to provide better intelligence for the United 
States. The Navy responded that they were working on the 
development of JFN/TES-N, and Congress then urgently funded 
development of the TES-N for rapid deployment. According to 
CAPT Albert Thomas from NAVSEA IWS 6C: 

After 9/11, Navy received emergency supplemental 
funding (DERF) to rapidly deploy NFN capability 
in the form of TES-N installations and JSIPS-N, 
GCCS-M, and communications upgrades. In parallel 
with executing these wartime operational 
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deployments, the NFN Program office is developing 
plans to continue spiral development and 
acquisition of ... the TES-N. (NFN Read Ahead for 
N76) 

Therefore, the Navy adopted an acquisition policy for 
the TES-N, which is known as Evolutionary Acquisition 
following a Spiral Development . 

C. THE TES-N EVOLUTIONARY ACQUISITION SPIRAL DEVELOPMENT 
PROCESS 

The TES-N was developed due to an urgent and strong 
need by the Navy for the intelligence capabilities 
(described above) which the TES-N could provide to the 
warfighter. Therefore, the normal way of starting an 
acquisition, with a MNS and an ORD, was not followed. 
Instead, there was direct approval from a Vice Admiral to 
start development of the TES-N (due partially to the fact 
that the Army had already developed their own TES). 
(Thomas, Interview, 2002) 

Initially the Army had developed the TES-A with 
Evolutionary Acquisition following a Spiral Development, so 
the Navy joined the Army Evolutionary Acquisition following 
a Spiral Development of TES, which led to the Joint 
Commonality Board being formed. In order to fully 
understand the notion of Evolutionary Acquisition following 
a Spiral Development that the TES took, one must understand 
what the JCB is and what its roles are for the TES system. 
As discussed in Chapter II, the JCB was formed earlier by 
the Army to help organize the development of the TES 
throughout all of the services . More specifically, the JCB 
has a role of forming and maintaining the Integrated 
Product Team (IPT) for the TES system development. Each IPT 
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is co-managed by the government and a contractor, and each 
IPT has a chief engineer that it must answer to about its 
part of the system. There are teams for functions such as 
security, SIGINT, fielding, and many more. Figure 3 shows 
how the TES IPTs are structured. Each IPT has 
representatives from each service to make sure that their 
service's needs are being met with each spiral of the TES. 


TES IPTs 


CHIEF ENGINEER 


SECURITY 


SOFTWARE 


BATTLE MGMT & TGTG 




COMMS 


SIGINT 


INTEGRATED EQUIP 




ILS 


NAT IMINT 


INTEGRATION & TEST 




SIM & TRNG 


TAC IMINT 


FIELDING 


XINT & DATA SERVICES 


Figure 15. Shows the Different IPTs in the TES-N 
Program (From: Lajoie, PowerPoint Slides, 2003). 

This procedure provides checks and balances to assure 
that each service's user needs are being met. (Lajoie, 
Interview, 2003) . 

The TES-N Evolutionary Acquisition following a Spiral 
Development process was done in an 80/20-Spiral Development 
schedule. The figure below represents the 80/20-Spiral 
Development process. 
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Figure 16. This Figure Depicts the 80/20 Relationship 

of the TES-N Evolutionary Acquisition Following a 
Spiral Development Process. Entities Listed are 
Stakeholders for Each Process in the 80/20 
Relationship. (From: Lajoie, PowerPoint Slides, 2003). 


The 80/20-Spiral Development means that in the 
beginning of a spiral or for the first 80% of the spiral 
the decision making is done with the engineers having a 
lead role about the development or systems engineering part 
of the process, with the users in more of a reactor mode 
and the program office staying in the control mode. In the 
last 20 % of the spiral the user has more to say and acts 
in a more leading role, while the engineers act in more of 
the reactor mode, and the program office still behaves in 
the control mode. With this 80/20 relationship in mind, the 
Evolutionary Acquisition following a Spiral Development 
goes through a series of steps, which happen in parallel 
throughout the process. These steps are known as USER 
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FEEDBACK 


JCB, BUILD PROCESS 


and STATUS . In the USER 


FEEDBACK step, the program office and engineers receive 
feedback from users and actions such as the fleet. Mobile 
training Teams (MTT), command visits, CFFC testing, the 
DOTMLPF filter, and institutional training. Next the JCB 
looks at the user requirements and decides which user 
requirements will be changed in the next spiral of the 
system (the Navy representative on the JCB serves as an 
advocate for fleet requirements) . They evaluate such things 
as risk, funding allotted, and recommendations from 
different (IPT) . Once a list has been made, the BUILD 
PROCESS step lasts a maximum of one year . In this step 
engineers design, develop, test, and upgrade the new TES 
(and therefore TES-N) system. In the last activity, STATUS, 
the program offices and IPT analyze what requirements were 
met and then distribute the new system. The process then 
starts all over again with the user assessing the new 

system and coming up with feedback to improve it. With each 
new run through these four activities, a new spiral is 

formed in the development of the TES (and therefore the 
TES-N) . 

More specifically, the TES-N program office built the 
basic system with a test software version 1.0 in early 
1999. They never fielded version 1.0, but with their in- 

house testing of it came up with a list of deficiencies . 

They quickly corrected these deficiencies and within the 
same year developed and fielded version 2.0. The next 
figure gives an idea of what new software was developed in 
each TES-N spiral. 
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Figure 17. This Figure Shows What Changes Were Added to 

the Software in Each Spiral of the TES-N (From: 

Lajoie, PowerPoint Slides, 2003). 

D. WHERE THE TES-N PROGRAM IS CURRENTLY AND WHAT IS THE 

FUTURE OF THE PROGRAM 

1. Current 

Since the TES-N followed an Evolutionary Acquisition 
following a Spiral Development form of acquisition, the 
system currently has no Acquisition Category or Navy MDA, 
per se. The NFN (now known as JFN) MNS which was signed on 
13 Feb 02 recommended an ACAT III designation, but that has 
not been officially adopted. But, the TES-N does get a 
great deal of oversight from many masters, to include PEO 
IWS, all three SYSCOMS (but primarily NAVSEA), the Virtual 
Program Office, and the OPNAV staff. (Burns, 2003) Below is 
a more complete list of TES-N stakeholders: 
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PEO IWS 


JFN 


• PEO LSC - DDX 

• PEO SHIPS - CVN 77 DEVELOPMENT 

• PEO SUBMARINES - FLORIDA, SSGN 

• NIMA - IMAGERY OVERSIGHT 

• AGENCY - CLASSIFIED 

• JCS - TES-J 

• MDA - PROJECT K/DSP 

• JTAMDO - SWA OPERATIONS/ATTACK OPS 

• ESC, HANSCOM - ISRM 

• NAVAL RESERVES - LSS 

• MARCORSYSCOM - TEG, RTC 

• ASPO - TES 

• APL - JTAAC 

• PEO IEW&S - DCGS ARMY 

• MOBSTR - PROGRAM OFFICE 

• ETP - PROGRAM OFFICE 

• DARPA - MTES/AMSTE II/SIAP 

• JFCOM - JACKNIFE ACTD 

• ONR - X, KU BAND PHASED ARRAY ANTENNA DEVELOPMENT 

• SAP - PROGRAM OFFICE 

• NAVAIR - HARRY BUFFALO, EA-6B, JSOW (AMSTE II) 

• AFRL - TUT 

• FUTURE: COAST GUARD - DEEP WATER (Burns, 2003) 

Next, another important document which is called the 
TES ORD by the TES-N program office is currently the 
original Army ORD used with the TES-A system. 
Unfortunately, there is still not an approved TES-N ORD, 
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but on the other hand, there is now a renewed move to 
produce a JFN ORD, which has been in development (and has 
fallen in and out of favor) since last summer. (Burns, 
2003) As for the TES-N position in the Evolutionary 
Acquisition following a Spiral Development process, it 
currently has a fielded, tested, and trained software 
version 5.0.5. The program office has recently been working 
on Build 5.2, which is essentially a "patch" that provides 
the capability to test and demonstrate SHARP tactical 
Imagery capability in TES-N. Build 5.2 is only being 
deployed to Fallon for testing. The next Version, 6.0, is 
in the development/testing stage of the spiral development 
process and will be delivered this fall. Build 5.2 
capability will be incorporated into the 6.0 software. 
(Burns, 2003) 

2. Future 

The JFN/TES-N will continue to be updated with new 
software, and the Honorable Mr. Young's recent guidance 
states that the Navy will converge its JFN architecture 
onto a TES-N baseline. How that convergence will take 
shape is still to be determined, but one can possibly 
foresee ideas such as JSIPS-N capabilities like Precision 
Targeting Workstation (PTW) and JSIPS-N Concentrator 
Architecture (JCA) being integrated into TES-N. (Burns, 
2003) 

E. EVOLUTIONARY ACQUISITION FOLLOWING A SPIRAL 
DEVELOPMENT OR A TAILORED "TRADITIONAL" PROCESS 
(SIMILARITIES AND DIFFERENCES) 

The JFN/TES-N program used Evolutionary Acquisition 
following a Spiral Development as described by Johnson and 
Johnson and a little of the "traditional" policy described 
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in the 5000 series publications. In this thesis I have used 
the Johnson and Johnson model for Evolutionary Acquisition 
following a Spiral Development and the 5000 series 
documents to describe the "traditional" process to 
emphasize key points such as the Requirements Definition, 
Acquisition Strategy, and test and evaluation procedure 
that highlight relative differences between the two as a 
basis for characterizing the TES-N acquisition process. 

The first key point was that the JFN/TES-N program was 
developed with urgency, and from a previously developed 
military technology. These two characteristics immediately 
provide a fitting reason, as according to Chapter IV, to 
consider executing Evolutionary Acquisition following a 
Spiral Development. Additionally, in the TES-N program, the 
Program Manager CAPT Albert Thomas, continuously gathers 
feedback about user needs from operators and decision 
makers using TES-N. But, the TES-N program office did not 
initially produce a MNS or ORD to get approved for 
development of their system. (Thomas, Interview, 2003) 

In comparing this to the Johnson and Johnson model, 
some of this activity occurs in what these authors call the 
Requirements Definition phase of a program. During, this 
activity the user is involved up front and needs to be 
continuously consulted for each spiral of the development. 
Next in the Requirements Definition phase, the program 
office must establish a SRD, but this did not happen in the 
TES-N program. The user's essential requirements for the 
system are listed in the SRD, but the user also understands 
that the system will be less than 80% effective. The TES-N 
program did not have an SRD, but consulted an old ORD from 
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the Army TES-A program. They also, later in the program 
development, produced a MNS that was similar to the 
"traditional" approach outlined in the 5000 series 
documents, but was not written in the order that the 
"traditional" approach follows . Below is an example of an 
objective from the MNS of the JFN/TES-N program. It states: 

Objectives. To generate targets by collecting and 
collating detection data gleaned from a variety 
of dispersed sensors and sources including sub¬ 
surface, surface, air-breather or space-based, 
fusing and transmitting that data to cognizant 
commanders for threat evaluation, and engagement 
platforms for weapons assignment in support of 
the Joint Force Commander's objectives. This MNS 
documents the need to convey relevant information 
required by the warfighter throughout the 
"Detect-Control-Engage" sequence. (Mission Need 
Statement For Naval Fires Network (NFN) ACAT III, 

p. 2) 

This MNS does reflect the 5000 series publications but 
it was not done in the same sequence as the 5000 series 
documents . This MNS statement was produced after 
development and fielding of the system had taken place, not 
before the system was approved for Concept Exploration. 

Next, the program office had an Acquisition Strategy 
for putting the requirements into action. In the TES-N 
program, this was done through the JCB and the TES IPT. The 
JCB and TES IPT provided constant communication for the 
project. In visiting the program office, CAPT Thomas seemed 
busy, continuously finding new user requirements and then 
vetting out which ones could be solved and which ones would 
be held to the next spiral. This gave me the idea that he 
understood that his program never had an end capability and 
that it would always be changing to take advantage of 
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changing technology. According to Johnson and Johnson, in 
the Acquisition Strategy for Evolutionary Acquisition 
following a Spiral Development, the Program Manager 
constantly looks for new user requirements for the next 
spiral and they understand that there is flexibility in 
their program, meaning there is no need to be rigidly fixed 
on the end product. This was similar to what happened with 
the TES-N program. 

Next, the testing community in an Evolutionary 
Acquisition following a Spiral Development also cannot be 
fixed on the end capability. The TES-N program did not 
follow the "traditional" test and evaluation phase, due to 
the fact that they had no ORD to be tested, and they still 
wanted a fast development of the capability. (Lajoie, 
Interview, 2003) Instead, testing was done in events such 
as LOE and FBE. For example, a TES-N prototype was 
successfully demonstrated in Fleet Battle Experiment-India 
(FBE—I), an exercise event involving all four services 
conducted in June 2001. Based upon this successful 
demonstration, COMTHIRDFLT recommended immediate deployment 
of JFN aboard USS JOHN C. STENNIS (CVN 74) and USS ABRAHAM 
LINCOLN (CVN 72), with COMNAVAIRPAC citing JFN as a 
"critical capability." (Burns, 2003) CNO (N7) recommended 
immediate acquisition and deployment of JFN/Time Critical 
Strike capability. In July 2001, the Assistant Secretary 
of the Navy (Research, Development and Acquisition) (ASN 
RDA) designated a Naval Fires Network/Time Critical Strike 
Program Director to integrate and synchronize acquisition 
and deployment activities across the Navy's Systems 
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Commands. Currently there is no efficient testing procedure 
on Evolutionary Acquisition following a Spiral Development, 
but doctrine is being developed. (Burns, 2003) 
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VI. CONCLUSIONS 


This chapter provides conclusions and recommendations 
on what can be improved and what should be used in future 
acquisition programs such as the TES-N. 

Evolutionary Acquisition following a Spiral 


Development 

shown with 

the 

TES-N system is an 

acquisition 

policy of the future . 

This 

thesis shows that Evolutionary 

Acquisition 

following 

a 

Spiral Development 

with 

the 

JFN/TES-N 

system is 

an 

acquisition policy 

that 

is 

appropriate 

for programs of 

the same size and 

scope. 

but 


larger more complex programs will not have as much success. 
This Evolutionary Acquisition following a Spiral 
Development for small/low complexity programs provides 
faster implementation of the system, involves the user 
throughout the process, and allows each service to be up to 
date with the changing effects of technology. Yet, despite 
all these benefits, there is still some work that must go 
into other policies that affect Evolutionary Acquisition 
following a Spiral Development. After a more in-depth look 
into the TES-N program, one can see that future programs 
following this type of acquisition policy will have issues 
with areas such as budgetary submission, the role of 
OPTEVFOR in their programs, policy, process, and training. 

A. OPINIONS AND BENEFITS 

In interviewing many officers, I found that varying 
opinions have been formed regarding JFN/TES-N in the Navy. 
According to CAPT Paul Hill, SPAWAR 05 Deputy for JFN, the 
JFN/TES-N, system-of-systems, has shown that Evolutionary 
Acquisition following a Spiral Development will provide 
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tremendous improvements in technological capabilities and 
attributes, but it has also proved that it is way ahead of 
its CONOPS. (Hill, 2003) This means that the technology is 
updated effectively but the support, logistics, and 
training policies cannot keep up with these new 
capabilities. Listed below are attributes and capabilities 
of TES-N received from the Program Office. Next, CAPT 
Christopher Bott, Commander Third Fleet, J2, stated that 
the JFN/TES-N concept of a single box capability, which 
allows access in real time, is a good one. He further 
states TES-N is nearly ready but still is lagging with 
inter-system problems between TES-N and GCCS-M; in 
addition, the graphics could be improved. (Bott, 2003) 
Furthermore, CDR Olivarez, a strike Commander aboard the 
USS CORONADO, he commented that when he was aboard the USS 
LINCOLN, he found that not many operators knew how to use 
the TES-N. In addition, operators and aviators needed to 
understand each other's requirements for TES-N. (Olivarez, 
2003) 

B. LIST OF CAPABILITIES AND ATTRIBUTES THAT JFN/TES-N 
PROVIDED 

• Attributes: 

• Competitive award 

• 100% Government owned 

• Non-proprietary 

• Spiral development 

• Configuration managed by a 4 Service JCCB 

• Common software baseline 

• Over 65% of content by other contractors 

• Common workstations for all Services 
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Multi-INT architecture: 










• Sensor access, control and management 

• Situational awareness 

• Mission planning and monitoring 

• Exploitation 

• Communications and dissemination 

Software Architecture: 

• Open and Non-proprietary 

• ICDs and APIs documented but controlled by 

Government 

• Commercial standards compliant 

• Over 115 COTS/GOTS products integrated 

• IP based internal and external network 
interfaces 

Scalable: 

• Hosted on a variety of platforms across all 
Services; Vannized, shipboard, rack mounted, 
transit case, and airborne 

• Software is issued in a configuration- 
managed version across all Services. 

• Major upgrade typically once per year, minor 
upgrades as needed. 

• Service may chose not to purchase a 
particular COTS license (capability not 
fielded). 

Jointness: 


Over 40 systems fielded and operating world¬ 
wide 

OIF supported by a TES variant from each 
Service 

Supports National thru Unit level 
Sharing, files, data, Intel daily 
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• Footprint TES supports other disadvantaged 
nodes 

• Army: TES Forward, TES Main, DTES 

• Navy: TES-N, RTC, RTC Lite 

• USMC: TEG, RTC 

• Air Force: ISR-M Host, ISR-M Remote (Burns, 
2003) 

Even with these impressive capabilities, the JFN/TES-N 
acquisition still encountered issues in other policies that 
needed to be addressed. This includes policies in budgetary 
submissions, test and evaluation, general policy and 
process in the Navy, and training. 

C. DRAWBACKS: FUNDING, TEST AND EVALUATION, POLICY, 

PROCESS, AND TRAINING 

The TES-N, due to its acquisition policy of 
Evolutionary Acquisition following a Spiral Development, 
did not use traditional methods in funding, test and 
evaluation, policy, process and training. In order to avoid 
similar problems in Evolutionary Acquisition following a 
Spiral Development for future programs following this new 
acquisition policy, there must be new procedures for test 
and evaluation, budgetary submissions, policy, process, and 
training in the Navy. 

1. Funding 

a. Problem 

Traditionally, as according to the 5000 series 
documents and as described in Chapter III, funding is 
conducted according to the Planning, Programming, and 
Budgeting System (PPBS). The TES-N program could only 
partially follow the guidelines of the PPBS because they 
used the Army's funding documents of the TES-A program. The 
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TES-N program office can realistically provide an estimate 
of how much money they intend to spend over the next 

several years and what they intend to use it for, but in 
reality, due to the Evolutionary Acquisition following a 
Spiral Development, the program office only knows how much 
funding they will need in the future once the users' 
feedback is obtained. User feedback is only received after 
the new development is brought into the fleet; therefore 

the time constraints for Evolutionary Acquisition following 

a Spiral Development do not allow for a funding policy that 

acts in accordance with the PPBS. Moreover, other programs 
like the TES-N might not have prior programs to base 
funding on for the PPBS. In conclusion, since each spiral 
depends on the previous spiral there is no way a program 
manager can produce a Program Objectives Memorandum (POM) 
for years in the future. (Lajoie and Thomas Interviews, 
2003) 

jb. Solution 

In my opinion there is not yet a clear and 

definite answer to this problem. A recommendation based 
upon research for this thesis would be that Program 

Managers of Evolutionary Acquisition following a Spiral 
Development need to work on explaining and teaching to the 
budgetary submission analysts how Evolutionary Acquisition 
following a Spiral Development works and that funding 

requirements are obtained only once user feedback is 

received. The Program Managers need to do this until the 
budgetary submission analysts buy into the unique funding 
developments of Evolutionary Acquisition following a Spiral 
Development. 
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Test and Evaluation 


2 . 

a. Problem 

For each new development of a system, there must 
be some sort of test and evaluation to determine if the 
system is ready for delivery to the fleet. In the 5000 
series documents, and as explained in Chapter III, the 
testing role is lead by OPTEVFOR. This process is usually a 
very long and detailed process. Since the TES-N was 
developed in Evolutionary Acquisition following a Spiral 
Development for quick fleet operational capability, it 
bypassed the OPTEVFOR stage and went directly to the 
certification stage for implementation into the fleet. 
Later in the TES-N development program. Commander Fleet 
Forces Command (CFFC) requested OPTEVFOR to test TES-N, but 
OPTEVFOR was not sure what or how to test since there was 
no new ORD produced and the Army ORD had already been 
tested. In conclusion, this part of the TES-N acquisition 
needs to be revised for future systems so OPTEVFOR can 
clarify and then fulfill its role in testing a program that 
has Evolutionary Acquisition following a Spiral 
Development. (Lajoie, Interview, 2003) 

b. Solution 

According to a contractor for JFN's resource 
sponsor, N61, David Loneman, one cannot do away with Test 
and Evaluation (T&E) and the role of the testers (OPTEVFOR) 
but the internal organization needs to be changed. If you 
did away with T&E the fleet would not feel comfortable 
using the product developed. A solution to this might be 
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hiring more people so the process of test and evaluation is 
faster to keep up with technology but still is as 
efficient. (Loneman, 2003) 

Due to the changing policies in acquisition, I 
believe the role of OPTEVFOR and documentation on 
parameters for testing should be changed, too. For example 
with the JFN/TES-N, the Evolutionary Acquisition following 
a Spiral Development was done in an 80/20-Spiral 
Development schedule. Usually OPTEVFOR tests compliance 
with the ORD but in Evolutionary Acquisition following a 
Spiral Development no ORD requirements will be initially 
produced. In my opinion with this 80/20 relationship in 
mind, OPTEVFOR should be provided different levels of ORD 
requirements to review. This would include initial testing, 
midterm testing and then a final testing when each 
requirement is met (the final testing might not come for 
many spirals so they would have to be patient). So 
initially we would have more of a 70/20/10 relationship 
(Engineers, Users, OPTEVFOR). OPTEVFOR needs to be involved 
early in the project to make sure the project is safe, 
while at the same time not delaying the program for fleet 
use. Then at midterm a 60/20/20 relationship (Engineers, 
Users, OPTEVFOR) should be used in Evolutionary Acquisition 
following a Spiral Development. Finally when capability is 
complete then it would become a 40/40/20 relationship. This 
means OPTEVFOR is always in on the workings of the program 
and does not have to wait to the end to test. According to 
VADM (RET) Ted Parker, this kind of arrangement for 
OPTEVFOR I suggested above can work, and has worked in the 
past. He also commented on other suggestions such as: 
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Getting OPTEVFOR OTDs involved very early is 
healthy for any program and especially important 
if one is not quite sure what the route is to the 
final set of requirements. If this is done, the 
OTDs gain better understanding of what the 
developmental item really is, and can apply 
better judgment to issues that arise. In my 
experience, this permits a. much more opportunity 
for DT&E to produce data that is useful to 
Operational Evaluation of the system. Sometimes, 
it just requires a simple change (that can be 
suggested by the OTD) to make a test that has no 
operational content into one that has enough 
operational content that the results can be 
applied toward IOT&E. b. utilization of more DT&E 
data and better understanding of the system. This 
will usually avoid the problem of dumb tests 
being conducted and paid for (saves money and 
time). c. better thinking by the PM, because 
he/she will have an opportunity to understand the 
needs of the OTD and can get ready for them (do 
better in OT&E). (Parker, 2003) 

In conclusion, OPTEVFOR and program offices that 
use Evolutionary Acquisition following a Spiral Development 
need to work together to make a test and evaluation policy 
that will be efficient with this new form of acquisition. 

3. Policy and Process 
a. Policy 

(1) Problem. Some policies of the Navy need 
to be changed. Policy was done differently for the JFN/ 
TES-N form of acquisition. For example, there was constant 
leadership throughout this program. The Navy made a 
decision to leave the Program Manager, CAPT Thomas, in the 
same position since 1996. In acquisition programs such as 
Evolutionary Acquisition following a Spiral Development it 
is critical to have the same leadership since it takes a 
long time to understand issues and make changes to the 
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program. If they had reassigned him the program would have 
eventually collapsed or fell behind. (Thomas, Interview, 
2003) 

(2) Solution. According to CAPT Thomas, 
the Program Manager for the JFN/TES-N, the Department of 
the Navy should change their officer career path for 
acquisition. For example, the pipeline would continue as 
normal until X.O. level. At X.O. level, the board would 
screen officers for acquisition billets. Then, if awarded 
acquisition billets those officers would spend the next 15 
years, plus, in acquisition. They would first act as Deputy 
Program Managers so that they would get initial 
understanding of the job. According to CAPT Thomas, it 
takes time to understand the Program Manager concepts. 
Next, the Navy would promote a percentage of the Deputy 
Program Managers to Program Managers. As Program Managers, 
they would stay on that specific program until the project 
was complete or they were deemed incompetent. Also, by not 
moving them until the project was finished, it would let 
the Program Manager's workers know that he/she was not 
going anywhere, which would curtail "slow rolling" to wait 
for change of leadership. (Thomas, Interview, 2003) 

Within this new policy, one needs to ensure 
integrity in the system being worked on. An answer to this 
would be to give a bonus to keep the Program Managers from 
retiring and working for the contractor when they retire. 
Next, there needs to be a structure to account for human 
nature. Most people in the acquisition business seem to be 
very ambitious, aggressive, and very competent. But, when 
there are large sums of money involved, people can be 
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corrupted. Therefore everyone involved in the project needs 
to have a personal interest to be successful. (Thomas, 
Interview, 2003) 

jb. Process 

(1) Problem. This program also reveals a 
struggle that the Navy has in its process and a problem 
that might hold back future progress in fielding 
technological support to this program. This problem builds 
back up for user buy ins and training. For example, since 
Evolutionary Acquisition following a Spiral Development has 
been adopted it has created tension between three different 
groups of people: OPTEVFOR and the developers, the 
operators of the TES-N and the idea of having new system 
ownership, and tensions between the different mentalities 
of the Pacific and Atlantic Fleets. In LCDR Matt Hopson's 
opinion, the J2 Systems officer on USS CORONADO, the 
capabilities of TES-N are there but there is a lack of 
teamwork and proficiency throughout the project. For 
example, OPTEVFOR needs to work with the developers, and 
the developers need to work with OPTEVFOR to find a way to 
efficiently test the Evolutionary Acquisition following a 
Spiral Development process without taking four years, and 
still keeping in mind that the capability is not yet 
finished. The Navy also needs to challenge its operators to 
take ownership of the new system and work with each other 
to make sure it is producing the correct display of data. 
Finally, there needs to be an alliance between the Pacific 
and Atlantic Fleets to install this system in both fleets 
at the same time. This system is supposed to provide 
interoperability between all the services, but the Pacific 
Fleet is the only one using it in the Navy. Thus, the Navy 
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has moved away from this stovepipe philosophy with 
Evolutionary Acquisition following a Spiral Development and 


it needs 

to do 

this also with its 

processing 

procedures. 

(Hopson, 

2003) 






(2) Solution. One 

possible 

solution 

according 

to 

Destiny Burns from 

the program office. 


involves creating greater fleet ownership of the system 
through an institution of combined formal schoolhouses, on¬ 
site training, and more "train-the-trainer" type of 
activities, establishment of formal TES-N/JFN billets and 
transition of logistics activities from the contractor to 
the fleet. (Burns, 2003) An example of a near term plan 
related to these tasks is that during Fiscal Year 2003, the 
JFN Program Office established a customer support strategy 
to engage Fleet users in the assessment/development of a 
Performance Based Logistics (PBL) strategy in accordance 
with ASN (RDA) Memorandum PBL Guidance Document of 27 Jan 
2003. Interim Defense Acquisition Guidebook of 30 Oct 2002 
states that Program Managers shall establish logistics 
support concepts and refine concepts throughout program 
development. JFN shall coordinate program requirements for 
support across functional areas to minimize redundant 
contract deliverables and inconsistencies. A JFN Product 
Support Plan is being developed for all fielded JFN 
systems. The Product Support Plan includes methods and 
tools to track system performance, such as designation of a 
JFN System Officer associated with each fielded system, to 
enhance coordination and implementation of formal and 
informal reporting and feedback procedures such as: 
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Sailor-to-Engineer Website Access 
Navy Integrated Call Center 
Remedy Database (Burns, 2003) 


Another key JFN Integrated Logistics Support 
(ILS) strategy is the transition of depot support, sparing, 
and maintenance support from contractor to government 
(fleet) control and responsibility. (Burns, 2003) 

4. Training 

a. Problem 

As everyone knows, technology can not be used if 
no one knows how to use it. The TES-N training system has 
caused a delay in the use of TES-N operationally. 
Currently, the normal training schedule is constant 
training on the system for ten days (65 hours) . TES-N is 
not typically used right away, so when the operators are 
about to use it they are given a quick refresher course. 
Therefore, there is a huge gap between training and system 
use, which causes proficiency to go drastically down. 
(Hopson, 2003) This will be viewed from the results of a 
survey I conducted on 06MAY03 and 07MAY03 given to the 
operators and decision makers of the JFN/TES-N aboard the 
USS CORONADO. 

Table 1 presents results of a survey used to rate 
the effectiveness of the JFN/TES-N training. It displays 
the mean score and range from lowest to highest for each 
question, using a seven-point scale. Participants were 
asked to rate the number on the seven-point scale with 
which they best agreed. The seven-point scale ranged from 
1= Not at all Effective or Extremely Difficult (depends on 
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the question) to 7 = Extremely Effective or Extremely Easy 
(depends on the question) . Below is an example of the 
scales used in the survey. 

1 _ 2 _ 3 _ 4 _ 5 ._ 6 _ 7 

Not Somewhat Moderately Very Extremely 

Very Extremely Effective Effective Effective 

Effective 

1 _ 2 _ 3 _ 4 _ 5 _ 6 _ 7 

Extremely Very Moderately Very Extremely 

Difficult Difficult Difficult/Easy Easy Easy 

The survey was administered to 11 operators and decision 
makers of the JFN/TES-N; 11 completed surveys were returned 
and analyzed. 


Survey Question Mean Range 


1. 

How effective was the training to operate 
TES-N? 

4 

(2-5) 

2 . 

How easy was it to learn to use the TES-N? 

3.6 

(2-6) 

3 . 

How effective was the actual process that 
was used (meaning combining all 
intelligence people to work together) to 
implement the new TES-N? 

4.7 

(2-6) 


Table 1. Results of Survey on Effectiveness of 

JFN/TES-N Training. 

The question that asked about the effectiveness 
of the TES-N training received a mean rating of 4, 
indicating that it was moderately effective. Two 
participants stated that the trainers/contractors were 
better suited for tech support than operator training. They 
explained that lots of training time was wasted due to the 
trainer's lack of operator experience with the machine. 
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Another participant stated that they had received only on- 
the-job training, which was helpful, but without formal 
training and constant use the training was not effective. 
Also an operator explained that the training was good but 
the UNIX environment that JFN/TES-N operated in was non¬ 
familiar and slowed the learning curve for many operators. 

The next question asked about how complicated the 
TES-N was to learn. The mean rating for this item was 3.6, 
indicating that it was more than moderately difficult. One 
participant stated that a reason TES-N was difficult to 
learn was because there were so many parts to JFN/TES-N and 
many operators and decision makers did not practice using 
them everyday. Another operator commented that it needed to 
be more user-friendly since the system step/functions were 
not intuitive and there were too many steps involved in 
completing one task. In contrast, another operator 
commented that it seemed fairly user-friendly, especially 
if you have a motivated instructor and get hands-on 
training, then anyone should be able to learn the system. 

The next question asked about the effectiveness 
of the actual process that was used (meaning combining all 
intelligence people to work together) to implement the new 
TES-N. The mean rating for this question was 4.7, which 
indicates that is was greater than moderately effective. 
One operator rated this item as a 5 since the proximity of 
all the intelligence sources and adaptation to the type of 
intelligence flow allowed more timely fusion of 
intelligence. Another operator agreed and said the process 
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was effective last summer for the Millennium Challenge 
Exercise. Another operator commented that better training 
would help the process run even smoother. 

With these survey questions analyzed I conclude 
that training of the TES-N needs to be improved. It seems 
that most operators and decision makers get on the job 
training and not formal training of the JFN/TES-N. If 

formal training is given then it is limited. Furthermore, 
hands-on experience with the system is not occurring after 
training is completed, therefore knowledge is lost. 
Furthermore most Navy personnel have been trained on 

Windows and not UNIX, which causes problems since the 
operating system of TES-N is UNIX. In addition, the 

training system also could be easier to utilize, meaning 
there are too many steps to complete a task. Finally, the 
TES-N process of combining all intelligence people to work 
together seems to work but would run smoother with more 

formal training and better doctrine. 

b. Solution 

A solution to the training dilemma might be to 
follow what the Army initially did. The Army did their 
initial training a different way. They formed a TES 
organization before they started the development of the 
TES-A. This organization included experienced operators who 
were hand picked. (Thomas, Interview, 2003) This 
integration went a lot smoother. Next, the Navy could have 
sent more people to the Army training center to get more 
formal training instead of on-the-job training for the 
JFN/TES-N. Finally, there should be a human factors 
training person involved in the initial spiral development 
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of the system so they can help ensure a good Human System 
Interface and document how to operate the new system as it 
is being developed. 

This thesis concludes that Evolutionary 
Acquisition following a Spiral Development shown with the 
JFN/TES-N system is an acquisition policy that is 
appropriate for programs of the same size and scope, but 
larger more complex programs will not have as much success. 
Yet, in order for the JFN/TES-N program and future programs 
using Evolutionary Acquisition following a Spiral 
Development to succeed changes have to be made in policies 
such as budgetary submissions, test and evaluation, policy, 
process, and training. 
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